fix(configurator): size-scale preview flattened button label font (card backdrop) - #601
Conversation
…scale font
The Components preview wrapped every button row in well() = .sf-card. The
framework's `.sf-card .sf-btn { --sf-btn-font-size--size: var(
--sf-card-btn-font-size, var(--sf-text-s)) }` rule pins any nested button's
label to text-s, so in the Size-scale demo all rungs rendered the SAME label
font while only padding/min-height grew — the per-rung font ladder (the whole
point of that section) was invisible, most obviously at narrow widths where the
fluid text steps all collapsed toward text-s.
Give the button rows a non-card framed surface (frame()) so each rung renders
its true --sf-text-{rung} label size. Cards keep .sf-card. Measured at 412px:
labels now scale xs 10.3 → s 12.9 → m 16.2 → l 20.3 → xl 25.5px (was a flat
12.9px across all rungs).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GnwqYHgHNAWPbsUJWUeY1w
|
Warning Review limit reached
Next review available in: 52 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (5)
📝 WalkthroughWalkthroughThe components preview adds a bordered surface frame helper and replaces ChangesButton preview layout
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested labels: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
The "Verify all generated artifacts" gate flagged demos/full-api-demo*.html and demos/ultimate-override.css as stale: the v0.7.15 release bump updated package.json but did not regenerate the committed demos, whose version banner still read v0.7.14. Regenerated via `node demos/generate.mjs` — the only change is the v0.7.14 → v0.7.15 stamp. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GnwqYHgHNAWPbsUJWUeY1w
Greptile SummaryThis preview-only fix replaces the
Confidence Score: 5/5Safe to merge — preview-only change with no framework or token modifications. The change is contained to a single file and affects only the HTML emitted by the configurator's preview gallery. Every CSS token in the new frame() function is a live framework token verified in the source. The well import remains valid and the cards section correctly keeps .sf-card. No files require special attention. Important Files Changed
Reviews (1): Last reviewed commit: "chore(demos): rebuild full-api demos for..." | Re-trigger Greptile |
There was a problem hiding this comment.
🧹 Nitpick comments (1)
configurator/src/lib/preview/sections.ts (1)
340-341: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueConsider extracting
frametospecimen.tsalongsidewell.
wellis exported fromspecimen.tsas a shared helper.framesolves the same category of problem (bordered surface wrapper) and is currently local tocomponents(). If another preview section needs a non-card framed surface in the future, the helper would need to be duplicated. Extracting it now would keep the wrapper helpers colocated and consistent.This is deferable — the local definition is fine for the current scope.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@configurator/src/lib/preview/sections.ts` around lines 340 - 341, Extract the local frame helper from components() into specimen.ts alongside the exported well helper, export it for reuse, and update components() to import and call the shared frame implementation while preserving its current markup and styling.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@configurator/src/lib/preview/sections.ts`:
- Around line 340-341: Extract the local frame helper from components() into
specimen.ts alongside the exported well helper, export it for reuse, and update
components() to import and call the shared frame implementation while preserving
its current markup and styling.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 93c2f613-dfeb-439e-aa5a-18ebbac0903e
📒 Files selected for processing (1)
configurator/src/lib/preview/sections.ts
Address CodeRabbit nitpick on PR #601: frame() solved the same category of problem as the exported well() (a bordered-surface wrapper) but was local to components(). Extract it to specimen.ts as a shared, exported helper so the two wrapper helpers stay colocated and reusable. Behaviour-preserving — identical markup and styling. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GnwqYHgHNAWPbsUJWUeY1w
Symptom
In the configurator's Components preview, the Size scale row rendered every rung's label at the same font size — the boxes grew (padding + min-height) but the
XS/S/M/L/XLlabels looked identical, most obviously at narrow (mobile) widths. Reported from the live site.Root cause
The preview wrapped each button row in
well(), which is a.sf-card. The framework intentionally shrinks buttons nested in a card:That rule overrides only the font-size
--sizetier (not padding/min-height), pinning every nested button's label to--sf-text-s. So inside thewell, all five rungs collapsed to one label size while their padding/min-height still scaled — hiding the per-rung font ladder that section exists to show. At narrow viewports the fluid--sf-text-*steps sit neartext-sanyway, making them visually identical.Measured (412px viewport), before: 12.9px flat across xs–xl.
Fix
Give the button rows a non-card framed surface (
frame(), a plain bordereddiv) instead ofwell(), so each rung renders its true--sf-text-{rung}label. The card sections (media card + modifiers) intentionally keep.sf-card.Measured after: labels scale xs 10.3 → s 12.9 → m 16.2 → l 20.3 → xl 25.5px — a clear staircase, confirmed visually in light + dark.
This is a preview-only change — the framework itself was always correct (a plain
.sf-btn--xloutside a card is--sf-text-xl); only the preview's card backdrop was masking it.Verification
tscclean,svelte-check0 errors,preview-coverage+ configurator unit (164) and component (25) suites pass.Notes
configurator/src/lib/preview/sections.ts); framework/tokens untouched.borders()well() usage left intact (only the Components button rows switched toframe()).mainsince feat(configurator): rebuild the Components live-preview tab from scratch #593 merged — fresh PR.🤖 Generated with Claude Code
Generated by Claude Code
Summary by CodeRabbit